Adaptive HTTP streaming (AHS) techniques are becoming more and more popular for providing video services. The adaptive HTTP streaming technique supports both video-on-demand and live video. Unicast transmission is typically used as default as a transport bearer. However, media segments can also be broadcasted to multiple receivers in a cell, for example using the broadcast mechanism in the Long Term Evolution (LTE) standard. FIG. 1 shows a typical network in which content or media from a web server 13 is streamed to a plurality of user equipment devices 11. The content is streamed via cells 10 associated with the user equipment devices 11, under control of a radio network controller 17. The web server 13 typically streams the content to the radio network controller via one or more nodes of a telecommunication network, such as a Gateway GPRS Support Node (GGSN) 15.
Adaptive HTTP streaming is a transport technique that uses existing file formats such as the Base Media File Format of the International Organization for Standardization (ISO BMFF) or the MPEG2-TS standard of the Moving Picture Experts Group. Different audio and video codecs are supported such as H.264, MPEG4, Advanced Audio Coding (AAC), mp3 codecs.
A number of different adaptive HTTP streaming solutions exist, such as HTTP Live Streaming (HLS) by Apple®, SmoothStreaming (ISM) from Microsoft®, 3GP Dynamic Adaptive Streaming over HTTP (3GP-DASH), MPEG Dynamic Adaptive Streaming over HTTP (MPEG-DASH), OITV HTTP Adaptive Streaming (OITV-HAS) of the Open IPTV Forum, Dynamic Streaming by Adobe® and many more. There is a possibility that the MPEG DASH solution will become the dominating standard for adaptive HTTP streaming.
The adaptive HTTP streaming techniques rely on the client to select the media quality. The server or content provider uses a “manifest file” to describe all of the different quality representations (media bitrates) that are available for streaming a particular content or media, and how these different quality representations can be accessed from the server. The manifest file is fetched at least once at the beginning of the streaming session and may be updated. In the case of the HLS technique by Apple®, the manifest is formatted as a Playlist file in the m3u8 format. In the case of 3GP/MPEG DASH, the manifest is an XML structure called the Media Presentation Description (MPD).
Most of the adaptive HTTP streaming techniques require a client to continuously fetch media segments from a server. A certain amount of media time (e.g. 10 sec of media data) is contained in a typical media segment. The creation of the addresses or URIs for downloading the segments of the different quality representation is described in the manifest file.
FIG. 2 depicts the basic principle of how segments may be fetched by an user equipment device 11, using an adapting HTTP streaming technique, from a server node 13. In steps 201 and 203 the user equipment device 11 fetches a manifest file from the server node 13. The user equipment device 11 processes the manifest file, and in step 205 fetches a first segment at a particular quality level, for example having the lowest quality level to begin with. The segment is fetched using a HTTP GET message. The user equipment 11 continuously measures the link bit-rate while receiving the media segments, for example while the first segment is being downloaded in step 207. Using this information about the link bit-rate the user equipment 11 is able to select a different representation or quality level, and sends a “HTTP GET Segment#2 from Medium Quality” message to the server node 13, shown in step 209. Upon receipt of the request, the server node 13 streams a segment at the medium quality level, step 211. The user equipment 11 may change to another quality representation at any time. For example, MPEG-DASH has defined a new indexing box, which allows user equipment devices to efficiently switch quality even in the middle of a segment download.
From the above it can be seen that, in adapting HTTP streaming, a video is encoded with multiple discrete bitrates and each bitrate stream is broken into multiple segments or “chunks” (for example 1-10 second segments). The ith chunk from one bitrate stream is aligned in the video time line to the ith chunk from another bitrate stream so that a user equipment device (or client device), such as a video player, can smoothly switch to a different bitrate at each chunk boundary.
The DASH “on-Demand” profile, which is promoted and used by applications such as NetFlix® follows a different scheme. The On-Demand profile is very close to HTTP progressive streaming, with the difference that the client may change the quality during playback.
In the case of the DASH “On-Demand” profile, the client requests video content using an open-range byte range request with HTTP. The client keeps receiving video content on the same HTTP pipe. Only in the case of quality switching, the client terminates the TCP connection and opens a new TCP connection for the next range request.
Either MPEG2-TS or ISO BMFF may be used as a file format for the media segments. MPEG2-TS is commonly known from the TV Broadcast environment. Other techniques such as HLS use MPEG2-TS. The Smooth Streaming technique by Microsoft uses Fragmented MP4 Files, which is defined as part of ISO BMFF. MPEG-DASH allows both ISO BMFF and MPEG2-TS as media segments. Additional ISO BMFF structures are defined to increase the robustness and feature-richness of DASH. 3GP-DASH is a profile of MPEG-DASH. A major difference is that only ISO BMFF is allowed. OIPF HAS (HTTP Adaptive Streaming) is also a profile of MPEG-DASH, supporting both ISO BMFF and MPEG2-TS file formats for media segments.
As mentioned above, adaptive HTTP streaming such as DASH or HLS is based on bitrate decisions made by user equipment devices. The user equipment device measures its own link bitrate and decides on the bitrate it would prefer for downloading content, typically selecting the highest available content bitrate that it predicts the available bandwidth can cater for.
When multiple user equipment devices are using an adaptive HTTP streaming service on the same network the bandwidth is often unfairly distributed among the user equipment devices, which can lead to unfairness.
For example, when multiple user equipment devices are using an adaptive HTTP streaming service on the same network they all compete over the available bandwidth (link throughput). If a user equipment device is fortunate enough to obtain a large share of the link bandwidth, that user equipment device will continue to experience rapid segment downloads and so continue to request a higher profile with larger segments. However, a user equipment device that only manages to obtain a smaller proportion of link throughput experiences a slower segment download and then is forced to request a lower rate profile with smaller segments.
The consequence of this is that adapting HTP streaming techniques are inherently unfair. Clients or user equipment devices that have been fortunate enough to get hold of a large chunk of the link throughput do not let it go, thus the unlucky user equipment devices tend to stay unlucky for the entire service session. This problem is particularly true in mobile/radio networks such as that shown in FIG. 1, where one or more cells can be congested. For service providers this is a problematic scenario, since having some of the end-users receiving poor quality downloads during an entire session results in a high risk that such end-users may stop using that service provider. A much better scenario would be if all end-users receive the same quality, even though this quality will be at a slightly lower quality than normal for some of the end-users.
A number of mechanisms exist for solving the unfairness problem in adapting HTTP streaming, for example in the form of various network solutions where network queuing schedulers or other control nodes are introduced in the network. Such mechanisms solve the problem using queuing mechanisms and scheduling how available bandwidth is shared between end-users. However, such systems have the disadvantage of requiring the network to be modified, which can be a hurdle for a service provider that is not in control of the network.